The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
Secure network “connections,” such as an IPsec deployment, are often configured according to a hub-and-spoke architecture. Such networks are established using point-to-point links among routers or switches that participate in the secure network. This is a natural and efficient way to set up encrypted networks since encryption involves establishing a shared secret between the two endpoints so that each endpoint can decrypt what the other endpoint has encrypted. For example, in hub-and-spoke networks in which spokes connect to a central private network, such as an enterprise LAN, via VPN links to a central hub or gateway at an interface to the central network, network traffic passes through the central hub to get to the central network.
Often, the spoke routers are connected to the network via DSL or cable modem links. It is typical for such routers to be assigned a network address dynamically, such as each time they reboot or reload. This scenario is common in VPN remote access deployments, as well as branch office connectivity deployments. Furthermore, network addresses dynamically assigned by network service providers often have a limited life or lease time and, therefore, expire after a certain period. Thus, upon expiration, a new address is often assigned to the device.
In deployments such as described above in which remote access to a central network is provided to multiple spokes, a management station behind the hub, such as an enterprise management station, often needs to connect to the spokes or to entities behind the spokes (collectively, “spoke devices”) to collect data or deploy configuration information. In order for a network entity, such as a management station, to connect to spoke devices, the entity needs to know the network address of the spoke devices to which it is connecting. However, as discussed, such network addresses are often dynamically assigned. Furthermore, there is not a strong association between a spoke device's dynamic address and its identity. Hence, the management station has no mechanism for locating a specific spoke of interest. The problem is compounded if the management station wants to identify not only spokes, but the users behind the spokes.
A traditional and common approach to network device address resolution involves use of DNS (Domain Name System). However, DNS has disadvantages. For example, resolution through a DNS server is insecure in that there is not cryptographic assurance that the network device is “who” it claims to be to the DNS server. In addition, traditional DNS is applicable to static address resolution. There are more recent offerings of dynamic DNS services, however, they experience the same shortcomings regarding security as described above.
The Security Architecture for the Internet Protocol and related protocols such as IKE and ISAKMP (collectively referred to as IPsec) provide a standards-based method of providing privacy, integrity, and authenticity to information transferred point-to-point among peers across IP networks, such as the public Internet wide area networks and private local area networks. Key management and security associations are negotiated with the Internet Key Exchange (IKE) protocol. A security association (SA) is a set of IPsec parameters that have been negotiated between two devices.
IPsec protocols define the concept of an IKE identity. IKE identification types (“ID types”) are used to identify a network device that is functioning as an IPsec endpoint and are separate from IPsec SA parameters. Such device identities are more “permanent” than network addresses, which, as mentioned, are often and frequently dynamically assigned. Furthermore, as part of an IKE process, IKE identities are cryptographically verified. Therefore, IKE identities are considered more secure than non-verified identities.
Security associations are typically stored at each network device that participates in secure communication using a network security protocol such as IPsec. For example, in the context of IPsec, security associations for secure connections negotiated by a given network device are stored in a Security Association Database (SAD) within the device. Hence, the SAD for a hub device maintains a list of related spokes and their associated SAs. The SAs are uniquely identified by a combination of a Security Parameter Index (SPI), a Destination IP Address (i.e., the spoke device's network address), and a security protocol (such as AH or ESP) identifier. Thus, each spoke device is identified in the SAD by its IP address, with no association with the spoke device's less transient IKE identity. Therefore, for example, if a management station behind a hub wants to connect to “spoke router A” or wants to connect to “Employee B's router,” there is no prior mechanism for trusted discovery of the dynamic network addresses of such routers.
Based on the foregoing, there is a clear need for a name resolution mechanism for identifying network devices at or behind secure connection endpoints. There is a more specific need for a name resolution mechanism for identifying such devices with dynamically assigned addresses.